Java Virtual Machine: Selami Penyetelan Garbage Collection

Kekuatan Java terletak pada kemandirian platformnya, yang dicapai melalui Java Virtual Machine (JVM). Aspek krusial dari JVM adalah manajemen memori otomatisnya, yang sebagian besar ditangani oleh pengumpul sampah (GC). Memahami dan menyetel GC sangat penting untuk performa aplikasi yang optimal, terutama untuk aplikasi global yang berhadapan dengan beban kerja beragam dan kumpulan data besar. Panduan ini memberikan gambaran komprehensif tentang penyetelan GC, mencakup berbagai pengumpul sampah, parameter penyetelan, dan contoh praktis untuk membantu Anda mengoptimalkan aplikasi Java Anda.

Memahami Garbage Collection di Java

Garbage collection adalah proses pengumpulan kembali memori yang ditempati oleh objek yang tidak lagi digunakan oleh program secara otomatis. Ini mencegah kebocoran memori dan menyederhanakan pengembangan dengan membebaskan pengembang dari manajemen memori manual, keuntungan yang signifikan dibandingkan dengan bahasa seperti C dan C++. GC JVM mengidentifikasi dan menghapus objek-objek yang tidak terpakai ini, membuat memori tersedia untuk pembuatan objek di masa mendatang. Pilihan pengumpul sampah dan parameter penyetelannya sangat memengaruhi performa aplikasi, termasuk:

• Jeda Aplikasi: Jeda GC, juga dikenal sebagai peristiwa 'stop-the-world', di mana utas aplikasi dijeda saat GC berjalan. Jeda yang sering atau lama dapat sangat memengaruhi pengalaman pengguna.
• Throughput: Tingkat di mana aplikasi dapat memproses tugas. GC dapat mengonsumsi sebagian sumber daya CPU yang dapat digunakan untuk pekerjaan aplikasi aktual, sehingga memengaruhi throughput.
• Pemanfaatan Memori: Seberapa efisien aplikasi menggunakan memori yang tersedia. GC yang dikonfigurasi dengan buruk dapat menyebabkan penggunaan memori yang berlebihan dan bahkan kesalahan kehabisan memori.
• Latensi: Waktu yang dibutuhkan aplikasi untuk merespons permintaan. Jeda GC secara langsung berkontribusi pada latensi.

Berbagai Garbage Collector di JVM

JVM menawarkan berbagai pengumpul sampah, masing-masing dengan kekuatan dan kelemahannya. Pemilihan pengumpul sampah bergantung pada persyaratan aplikasi dan karakteristik beban kerja. Mari kita jelajahi beberapa yang menonjol:

1. Serial Garbage Collector

Serial GC adalah pengumpul single-threaded, terutama cocok untuk aplikasi yang berjalan pada mesin single-core atau yang memiliki heap sangat kecil. Ini adalah pengumpul paling sederhana dan melakukan siklus GC penuh. Kelemahan utamanya adalah jeda 'stop-the-world' yang lama, membuatnya tidak cocok untuk lingkungan produksi yang membutuhkan latensi rendah.

2. Parallel Garbage Collector (Throughput Collector)

Parallel GC, juga dikenal sebagai throughput collector, bertujuan untuk memaksimalkan throughput aplikasi. Ini menggunakan beberapa utas untuk melakukan pengumpulan sampah kecil dan besar, mengurangi durasi siklus GC individu. Ini adalah pilihan yang baik untuk aplikasi di mana memaksimalkan throughput lebih penting daripada latensi rendah, seperti pekerjaan pemrosesan batch.

3. CMS (Concurrent Mark Sweep) Garbage Collector (Diusir)

CMS dirancang untuk mengurangi waktu jeda dengan melakukan sebagian besar pengumpulan sampah secara bersamaan dengan utas aplikasi. Ini menggunakan pendekatan concurrent mark-sweep. Meskipun CMS memberikan jeda yang lebih rendah daripada Parallel GC, ia dapat mengalami fragmentasi dan memiliki overhead CPU yang lebih tinggi. CMS telah diusir sejak Java 9 dan tidak lagi direkomendasikan untuk aplikasi baru. Ia telah digantikan oleh G1GC.

4. G1GC (Garbage-First Garbage Collector)

G1GC adalah pengumpul sampah default sejak Java 9 dan dirancang untuk ukuran heap besar dan jeda rendah. Ia membagi heap menjadi beberapa wilayah dan memprioritaskan pengumpulan wilayah yang paling penuh sampah, oleh karena itu namanya 'Garbage-First'. G1GC memberikan keseimbangan yang baik antara throughput dan latensi, menjadikannya pilihan yang serbaguna untuk berbagai aplikasi. Ia bertujuan untuk menjaga jeda di bawah target yang ditentukan (misalnya, 200 milidetik).

5. ZGC (Z Garbage Collector)

ZGC adalah pengumpul sampah latensi rendah yang diperkenalkan di Java 11 (eksperimental di Java 11, siap produksi dari Java 15). Ia bertujuan untuk meminimalkan jeda GC hingga serendah 10 milidetik, terlepas dari ukuran heap. ZGC bekerja secara bersamaan, dengan aplikasi berjalan hampir tanpa gangguan. Ia cocok untuk aplikasi yang membutuhkan latensi sangat rendah, seperti sistem perdagangan frekuensi tinggi atau platform game online. ZGC menggunakan pointer berwarna untuk melacak referensi objek.

6. Shenandoah Garbage Collector

Shenandoah adalah pengumpul sampah latensi rendah yang dikembangkan oleh Red Hat dan merupakan alternatif potensial untuk ZGC. Ia juga bertujuan untuk jeda yang sangat rendah dengan melakukan pengumpulan sampah secara bersamaan. Pembeda utama Shenandoah adalah ia dapat memadatkan heap secara bersamaan, yang dapat membantu mengurangi fragmentasi. Shenandoah siap produksi di OpenJDK dan distribusi Red Hat dari Java. Ia dikenal karena jeda rendah dan karakteristik throughputnya. Shenandoah sepenuhnya bersamaan dengan aplikasi yang memiliki manfaat tidak menghentikan eksekusi aplikasi setiap saat. Pekerjaan dilakukan melalui utas tambahan.

Parameter Penyetelan GC Utama

Penyetelan pengumpulan sampah melibatkan penyesuaian berbagai parameter untuk mengoptimalkan performa. Berikut adalah beberapa parameter penting untuk dipertimbangkan, dikategorikan untuk kejelasan:

1. Konfigurasi Ukuran Heap

• -Xms<size> (Ukuran Heap Minimum): Menetapkan ukuran heap awal. Secara umum, praktik yang baik adalah menetapkan ini ke nilai yang sama dengan -Xmx untuk mencegah JVM mengubah ukuran heap selama runtime.
• -Xmx<size> (Ukuran Heap Maksimum): Menetapkan ukuran heap maksimum. Ini adalah parameter paling penting untuk dikonfigurasi. Menemukan nilai yang tepat melibatkan eksperimen dan pemantauan. Heap yang lebih besar dapat meningkatkan throughput tetapi dapat meningkatkan jeda jika GC harus bekerja lebih keras.
• -Xmn<size> (Ukuran Young Generation): Menentukan ukuran young generation. Young generation adalah tempat objek baru dialokasikan pada awalnya. Young generation yang lebih besar dapat mengurangi frekuensi minor GC. Untuk G1GC, ukuran young generation dikelola secara otomatis tetapi dapat disesuaikan menggunakan parameter -XX:G1NewSizePercent dan -XX:G1MaxNewSizePercent.

2. Pemilihan Garbage Collector

• -XX:+UseSerialGC: Mengaktifkan Serial GC.
• -XX:+UseParallelGC: Mengaktifkan Parallel GC (throughput collector).
• -XX:+UseG1GC: Mengaktifkan G1GC. Ini adalah default untuk Java 9 dan yang lebih baru.
• -XX:+UseZGC: Mengaktifkan ZGC.
• -XX:+UseShenandoahGC: Mengaktifkan Shenandoah GC.

3. Parameter Khusus G1GC

• -XX:MaxGCPauseMillis=<ms>: Menetapkan target jeda maksimum dalam milidetik untuk G1GC. GC akan mencoba memenuhi target ini, tetapi tidak ada jaminan.
• -XX:G1HeapRegionSize=<size>: Menetapkan ukuran wilayah di dalam heap untuk G1GC. Meningkatkan ukuran wilayah berpotensi mengurangi overhead GC.
• -XX:G1NewSizePercent=<percent>: Menetapkan persentase minimum heap yang digunakan untuk young generation di G1GC.
• -XX:G1MaxNewSizePercent=<percent>: Menetapkan persentase maksimum heap yang digunakan untuk young generation di G1GC.
• -XX:G1ReservePercent=<percent>: Jumlah memori yang dicadangkan untuk alokasi objek baru. Nilai defaultnya adalah 10%.
• -XX:G1MixedGCCountTarget=<count>: Menentukan jumlah target pengumpulan sampah campuran dalam satu siklus.

4. Parameter Khusus ZGC

• -XX:ZUncommitDelay=<seconds>: Jumlah waktu, dalam detik, ZGC akan menunggu sebelum mengembalikan memori ke sistem operasi.
• -XX:ZAllocationSpikeFactor=<factor>: Faktor lonjakan untuk tingkat alokasi. Nilai yang lebih tinggi menyiratkan bahwa GC diizinkan untuk bekerja lebih agresif untuk mengumpulkan sampah dan dapat mengonsumsi lebih banyak siklus CPU.

5. Parameter Penting Lainnya

• -XX:+PrintGCDetails: Mengaktifkan logging GC terperinci, memberikan informasi berharga tentang siklus GC, waktu jeda, dan penggunaan memori. Ini penting untuk menganalisis perilaku GC.
• -XX:+PrintGCTimeStamps: Menyertakan stempel waktu dalam output log GC.
• -XX:+UseStringDeduplication (Java 8u20 dan yang lebih baru, G1GC): Mengurangi penggunaan memori dengan melakukan deduplikasi string yang identik di heap.
• -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses: Mengaktifkan atau menonaktifkan penggunaan pemanggilan GC eksplisit di JDK saat ini. Ini berguna untuk mencegah penurunan performa selama lingkungan produksi.
• -XX:+HeapDumpOnOutOfMemoryError: Menghasilkan heap dump saat terjadi OutOfMemoryError, memungkinkan analisis terperinci tentang penggunaan memori dan identifikasi kebocoran memori.
• -XX:HeapDumpPath=<path>: Menentukan lokasi tempat file heap dump harus ditulis.

Contoh Penyetelan GC Praktis

Mari kita lihat beberapa contoh praktis untuk berbagai skenario. Ingatlah bahwa ini adalah titik awal dan memerlukan eksperimen serta pemantauan berdasarkan karakteristik spesifik aplikasi Anda. Penting untuk memantau aplikasi untuk memiliki baseline yang sesuai. Juga, hasil dapat bervariasi tergantung pada perangkat keras.

1. Aplikasi Pemrosesan Batch (Fokus Throughput)

Untuk aplikasi pemrosesan batch, tujuan utamanya biasanya adalah untuk memaksimalkan throughput. Latensi rendah tidak begitu penting. Parallel GC seringkali merupakan pilihan yang baik.

java -Xms4g -Xmx4g -XX:+UseParallelGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar mybatchapp.jar

Dalam contoh ini, kami menetapkan ukuran heap minimum dan maksimum ke 4GB, mengaktifkan Parallel GC dan logging GC terperinci.

2. Aplikasi Web (Sensitif Latensi)

Untuk aplikasi web, latensi rendah sangat penting untuk pengalaman pengguna yang baik. G1GC atau ZGC (atau Shenandoah) seringkali lebih disukai.

Menggunakan G1GC:

java -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar mywebapp.jar

Konfigurasi ini menetapkan ukuran heap minimum dan maksimum ke 8GB, mengaktifkan G1GC, dan menetapkan target jeda maksimum ke 200 milidetik. Sesuaikan nilai MaxGCPauseMillis berdasarkan persyaratan performa Anda.

Menggunakan ZGC (membutuhkan Java 11+):

java -Xms8g -Xmx8g -XX:+UseZGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar mywebapp.jar

Contoh ini mengaktifkan ZGC dengan konfigurasi heap yang serupa. Karena ZGC dirancang untuk latensi sangat rendah, Anda biasanya tidak perlu mengkonfigurasi target waktu jeda. Anda dapat menambahkan parameter untuk skenario tertentu; misalnya, jika Anda memiliki masalah tingkat alokasi, Anda dapat mencoba -XX:ZAllocationSpikeFactor=2

3. Sistem Perdagangan Frekuensi Tinggi (Latensi Sangat Rendah)

Untuk sistem perdagangan frekuensi tinggi, latensi sangat rendah adalah yang terpenting. ZGC adalah pilihan yang ideal, dengan asumsi aplikasi kompatibel dengannya. Jika Anda menggunakan Java 8 atau memiliki masalah kompatibilitas, pertimbangkan Shenandoah.

java -Xms16g -Xmx16g -XX:+UseZGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar mytradingapp.jar

Mirip dengan contoh aplikasi web, kami mengatur ukuran heap dan mengaktifkan ZGC. Pertimbangkan untuk menyetel parameter khusus ZGC lebih lanjut berdasarkan beban kerja.

4. Aplikasi dengan Kumpulan Data Besar

Untuk aplikasi yang berurusan dengan kumpulan data yang sangat besar, pertimbangan yang cermat diperlukan. Menggunakan ukuran heap yang lebih besar mungkin diperlukan, dan pemantauan menjadi lebih penting. Data juga dapat di-cache di Young generation jika kumpulan data kecil dan ukurannya dekat dengan young generation.

Pertimbangkan poin-poin berikut:

• Tingkat Alokasi Objek: Jika aplikasi Anda membuat banyak objek berumur pendek, young generation mungkin sudah cukup.
• Masa Hidup Objek: Jika objek cenderung berumur lebih panjang, Anda perlu memantau tingkat promosi dari young generation ke old generation.
• Jejak Memori: Jika aplikasi terikat memori dan jika Anda mengalami kesalahan OutOfMemoryError, mengurangi ukuran objek atau membuatnya berumur pendek dapat menyelesaikan masalah.

Untuk kumpulan data besar, rasio young generation dan old generation penting. Pertimbangkan contoh berikut untuk mencapai jeda rendah:

java -Xms32g -Xmx32g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=30 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar mydatasetapp.jar

Contoh ini menetapkan heap yang lebih besar (32GB), dan menyetel G1GC dengan target jeda yang lebih rendah dan ukuran young generation yang disesuaikan. Sesuaikan parameter sesuai kebutuhan.

Pemantauan dan Analisis

Penyetelan GC bukanlah upaya sekali jalan; ini adalah proses berulang yang membutuhkan pemantauan dan analisis yang cermat. Berikut cara mendekati pemantauan:

1. Logging GC

Aktifkan logging GC terperinci menggunakan parameter seperti -XX:+PrintGCDetails, -XX:+PrintGCTimeStamps, dan -Xloggc:<filename>. Analisis file log untuk memahami perilaku GC, termasuk waktu jeda, frekuensi siklus GC, dan pola penggunaan memori. Pertimbangkan untuk menggunakan alat seperti GCViewer atau GCeasy untuk memvisualisasikan dan menganalisis log GC.

2. Alat Pemantauan Performa Aplikasi (APM)

Gunakan alat APM (misalnya, Datadog, New Relic, AppDynamics) untuk memantau performa aplikasi, termasuk penggunaan CPU, penggunaan memori, waktu respons, dan tingkat kesalahan. Alat-alat ini dapat membantu mengidentifikasi hambatan yang terkait dengan GC dan memberikan wawasan tentang perilaku aplikasi. Alat-alat di pasaran seperti Prometheus dan Grafana juga dapat digunakan untuk melihat wawasan performa real-time.

3. Heap Dumps

Ambil heap dumps (menggunakan -XX:+HeapDumpOnOutOfMemoryError dan -XX:HeapDumpPath=<path>) ketika terjadi OutOfMemoryErrors. Analisis heap dumps menggunakan alat seperti Eclipse MAT (Memory Analyzer Tool) untuk mengidentifikasi kebocoran memori dan memahami pola alokasi objek. Heap dumps memberikan snapshot penggunaan memori aplikasi pada titik waktu tertentu.

4. Profiling

Gunakan alat profiling Java (misalnya, JProfiler, YourKit) untuk mengidentifikasi hambatan performa dalam kode Anda. Alat-alat ini dapat memberikan wawasan tentang pembuatan objek, panggilan metode, dan penggunaan CPU, yang secara tidak langsung dapat membantu Anda menyetel GC dengan mengoptimalkan kode aplikasi.

Praktik Terbaik untuk Penyetelan GC

• Mulai dengan Default: Default JVM seringkali merupakan titik awal yang baik. Jangan melakukan penyetelan berlebihan sebelum waktunya.
• Pahami Aplikasi Anda: Ketahui beban kerja aplikasi Anda, pola alokasi objek, dan karakteristik penggunaan memori.
• Uji di Lingkungan Mirip Produksi: Uji konfigurasi GC di lingkungan yang sangat mirip dengan lingkungan produksi Anda untuk secara akurat menilai dampak performa.
• Pantau Terus-Menerus: Pantau terus perilaku GC dan performa aplikasi. Sesuaikan parameter penyetelan sesuai kebutuhan berdasarkan hasil yang diamati.
• Isolasikan Variabel: Saat menyetel, ubah hanya satu parameter pada satu waktu untuk memahami dampak setiap perubahan.
• Hindari Optimasi Prematur: Jangan mengoptimalkan masalah yang dirasakan tanpa data dan analisis yang kuat.
• Optimalkan Kode: Optimalkan kode Anda untuk mengurangi pembuatan objek dan overhead pengumpulan sampah. Misalnya, gunakan kembali objek jika memungkinkan.
• Tetap Terbaru: Tetap terinformasi tentang kemajuan terbaru dalam teknologi GC dan pembaruan JVM. Versi JVM baru seringkali menyertakan peningkatan dalam pengumpulan sampah.
• Dokumentasikan Penyetelan Anda: Dokumentasikan konfigurasi GC, alasan di balik pilihan Anda, dan hasil performa. Ini membantu pemeliharaan dan pemecahan masalah di masa mendatang.

Kesimpulan

Penyetelan pengumpulan sampah adalah aspek penting dari optimasi performa aplikasi Java. Dengan memahami berbagai pengumpul sampah, parameter penyetelan, dan teknik pemantauan, Anda dapat secara efektif mengoptimalkan aplikasi Anda untuk memenuhi persyaratan performa tertentu. Ingatlah bahwa penyetelan GC adalah proses berulang dan membutuhkan pemantauan dan analisis berkelanjutan untuk mencapai hasil yang optimal. Mulailah dengan default, pahami aplikasi Anda, dan bereksperimenlah dengan konfigurasi yang berbeda untuk menemukan yang paling sesuai dengan kebutuhan Anda. Dengan konfigurasi dan pemantauan yang tepat, Anda dapat memastikan bahwa aplikasi Java Anda beroperasi secara efisien dan andal, terlepas dari jangkauan global Anda.